Implantable stimulation devices deliver electrical stimuli to nerves and tissues for the therapy of various biological disorders, such as pacemakers to treat cardiac arrhythmia, defibrillators to treat cardiac fibrillation, cochlear stimulators to treat deafness, retinal stimulators to treat blindness, muscle stimulators to produce coordinated limb movement, spinal cord stimulators to treat chronic pain, cortical and deep brain stimulators (DBS) to treat motor and psychological disorders, and other neural stimulators to treat urinary incontinence, sleep apnea, shoulder subluxation, etc. The description that follows will generally focus on the use of the invention within a Spinal Cord Stimulation (SCS) system, such as that disclosed in U.S. Pat. No. 6,516,227. However, the present invention may find applicability with any implantable medical device or in any implantable medical device system.
As shown in FIG. 1, an SCS system typically includes an Implantable Pulse Generator (IPG) 10, which includes a biocompatible device case 12 formed of titanium, for example. The case 12 typically holds the circuitry and battery 14 necessary for the IPG to function. The IPG 10 is coupled to electrodes 16 via one or more electrode leads 18 (two of which are shown). The electrodes 16 are coupled to the IPG 10 at one or more lead connectors 20 fixed in a header 22, which can comprise an epoxy for example. In the illustrated embodiment there are sixteen electrodes, although the number of leads and electrodes is application specific and therefore can vary. In an SCS application, two electrode leads 18 are typically implanted on the right and left side of the dura within the patient's spinal cord. The proximal ends of the leads 18 are then tunneled through the patient's flesh to a distant location, such as the buttocks, where the IPG case 12 is implanted, at which point they are coupled to the lead connector(s) 20.
FIG. 2A shows a front view of an external controller 50 for communicating with the IPG 10, and FIG. 2B shows the external controller 50 and IPG 10 in cross section. Two coils (antennas) are generally present in the IPG 10: a telemetry coil 24 used to transmit/receive data via a wireless communications link 75 to/from the external controller 50; and a charging coil 26 for charging or recharging the IPG's battery 14 using an external charger (not shown). These and other components 25 necessary for IPG operation are electrically coupled to a circuit board 23. The telemetry coil 24 can be mounted within the header 22 of the IPG 10, or can be located within the case 12 as shown.
The external controller 50, such as a hand-held programmer or a clinician's programmer, is used to send or adjust the therapy settings that the IPG 10 will provide to the patient (such as which electrodes 16 are active, whether such electrodes sink or source current (polarity), and the duration, frequency, and amplitude (intensity) of pulses formed at the electrodes, etc.). The external controller 50 can also act as a receiver of data from the IPG 10, such as various data reporting on the IPG's status and the level of the IPG 10's battery 14. The external controller 50 is itself powered by a battery 52, but could also be powered by plugging it into a wall outlet for example. A user interface similar to that used for a cell phone is provided to operate the external controller 50, including buttons 54 and a display 58. The external controller 50 also includes a telemetry coil 56. These and other components 59 necessary for IPG operation are electrically coupled to a circuit board 57.
Wireless data transfer between the IPG 10 and the external controller 50 typically takes place via magnetic inductive coupling between coils 24 and 56, each of which can act as the transmitter or the receiver to enable two-way communication between the two devices. A Frequency Shift Keying (FSK) protocol can be used to send data between the two coils 24 and 56 via link 75. Although use of an FSK protocol in legacy systems is discussed below, use of this protocol is not universal, and other protocols employing different forms of modulation can be used to communicate between an external controller and an IPG, as one skilled in the art understands. Telemetry of data can occur transcutaneously though a patient's tissue 80.
Historically, external medical devices such as external controller 50 have been built by the manufacturer of the IPGs, and thus such external devices are generally dedicated to only communicate with such IPGs. The inventors have realized that there are many commercial mobile devices, such as mobile cell phones and multi-function tablets, that have the necessary configurable hardware and software to function as an external controller for an IPG or other implantable medical device. Using such mobile devices as external controllers for an implantable medical device would benefit both manufacturers and end users: manufacturers would not need to build dedicated external controllers that end users must buy, and end users could control their IPGs without the inconvenience of having to carry additional custom external controllers.
However, there are problems with this solution. Mobile devices are often configured with necessary hardware and software to communicate with other devices using short-range protocols, such as Bluetooth, Bluetooth Low Energy (BLE), Near Field Communication (NFC), Zigbee, and WiFi, as well as by using long-range cellular telephony protocols, any of which can be used to ultimately wirelessly connect the mobile device to the Internet or other network. While such communication channels allow for communication with an implantable medical device, they also render mobile devices less secure than traditional dedicated external controllers, particularly because they are prone to cyber attack, to computer viruses or malware, or to other intentional forms corruption. The multi-functional nature of mobile devices also makes them more prone to unintentional corruption, as their complicated nature may simply cause them to function improperly, even if they have not been intentionally corrupted. Thus, if mobile devices are used as medical devices to communicate with implantable devices, there is an increased risk that the implantable medical device could be mis-programmed and potentially injure a patient.
Implantable medical devices currently employ some level of security to determine whether communications it receives are valid and should be executed to change its operation. In this regard, it has been known in the art of IPGs to use ID codes and error codes, such as is illustrated in FIG. 3. As shown, data is telemetered from an external controller 50 to the IPG 10 in the form of a block 70, or in a series of blocks 70 in a longer, more-complicated communication session. A block 70 typically comprises a header 72, a message 74, and an error code 76 in sequence. The header 72 may include code understood by the IPG 10 as indicative of the beginning of a block 70, and may include other information such as the length or type of the message 74 to follow. The header 72 may also include an ID code 73 or address for the implantable medical device, and may also include an ID code for the external controller (not shown).
Message 74 comprises the main data “payload” of the block 70, which may further be divided into an instruction 78 and data 79 associated with that instruction. For example, instruction 78 might comprise an instruction to set or adjust therapy, with data 79 reflecting the particular settings to be set or adjusted (e.g., active electrodes, polarity, duration, frequency, intensity, etc.). Or instruction 78 might comprise an instruction for a particular therapy setting (e.g., to change, increase or decrease intensity), with data 79 reflecting the data for that therapy adjustment (e.g., the magnitude of the intensity, or a magnitude of an adjustment to the intensity).
An instruction 78 may also be unaccompanied by data 79, and an instruction 78 may cause other changes in the IPG 10 that when executed will not (directly) change therapy settings. For example, an instruction 78 may simply place the IPG 10 into a particular operational mode, such as a power down mode for power savings, a mode to ready the IPG for programming of new operation software, or to activate its telemetry circuitry to telemeter data back to the external controller 50, etc. For such instructions, accompanying data 79 may not be necessary. Message 74 may comprise multiple instructions 78, and/or multiple instructions 78/data 79 pieces, within a block 70, and message 74 can comprise a fixed or variable number of bytes.
The error code 76 appended to the end of the block 70 is used by the IPG 10 to determine whether the block has been corrupted during transmission, by electromagnetic interference for example. In the example shown in FIG. 3, the error code 76 comprises a Cyclic Redundancy Code (CRC). CRCs are well known, and are only briefly explained. A CRC is computed at the external controller 50 by dividing the block (i.e., the hexadecimal number comprising the header 72 plus the message 74) by a particular hexadecimal polynomial. The external controller 50 appends this CRC as the error code 76 to the block 70, which is transmitted to the IPG 10. On the receiving end, the IPG 10 likewise assesses the block (72 and 74) and computes a CRC using the same polynomial. If the CRC computed by the IPG 10 does not match the received CRC, the IPG will deduce that a transmission error occurred, e.g., a logic ‘0’ bit was inadvertently received as a ‘1’ bit, etc. In response, the IPG 10 can take appropriate action, such as discarding the block 70, or requesting the external controller 50 to resend that block.
If this error check passes at the IPG 10, the IPG 10 will next review the ID code 73 to ensure that the block 70 it received was truly intended for it. The IPG 10 may do this by comparing the received ID code 73 with an ID code stored, for example, in its memory. If the received ID code 73 does not match, the IPG 10 can take appropriate action, such as discarding the block 70.
If both the error check and ID code check pass, the block is deemed valid and the IPG 10 will accept and execute the block 70, such as by changing the stimulation intensity. It should be noted that review of the error codes and ID codes can occur in the opposite order, with the IPG 10 reviewing the ID code first and then the error code. Also, ID and error codes can likewise be employed when blocks are transmitted from the IPG 10 to the external controller 50 to allow the external controller 50 to determine whether blocks it receives from the IPG 10 are valid.
While ID codes and error codes provide some level of protection to prevent implantable medical devices from executing invalid blocks, they may not be sufficient, particularly given the potential use of more-easily-corruptible mobile devices as external controllers. For example, a corrupted mobile device could send a corrupt block containing an undesired instruction, or instruction with undesired data with or without patient intervention. Such a corrupt block could still be properly formatted at the mobile device, and could contain both a proper ID and an error. As such, this corrupt block would be deemed valid and executed at the implantable medical device, undesirably modifying operation of the implantable medical device potentially in a manner unsuitable for the patient. In an IPG, such improper operation could comprise an improper therapy setting, entry into an improper operational mode, etc.
Particularly if mobile devices are used as external controllers to communicate with implantable medical devices, the inventors believe that further security measures should be taken, preferably within implantable medical devices themselves, to protect against execution of potentially-corrupt communications they may receive.